自從在專案導入 TeamCity 後，就不再需要手動執行編譯和打包，除了可以省下開發者的時間外，也更容易管理應用程式的發佈檔案。不過其實 TeamCity 能幫我們做的不只這些，舉凡程式碼風格檢查、靜態分析、測試、產生文件…等都可以。換句話說，只要能夠將要做的動作變成 Terminal 可執行的指令，就可以讓 TeamCity 幫我們自動執行。而以 Kotlin 生態系來說，只要有 Gradle 指令，TeamCity 內建的 Gradle Runner 就幾乎無所不能！
今天的耕讀筆記，就以 Qodana 這套由 JetBrains 打造的程式碼品質檢查工具為例，示範如何用 TeamCity 在每次編譯和打包前自動掃描，並透過掃描報告了解專案的程式碼品質。
使用過 IntelliJ IDEA 的開發者應該都很熟悉 IDE 裡內建的 Code Inspection 功能吧？Code Inspection 可以協助開發者在寫程式碼的當下，就掃描程式碼是否符合 Code Style、是否能通過編譯、是否有潛在的問題。對開發者來說，能愈早發現問題，就能儘早修正，也因此像 Code Inspection 這種結合 Code Style 及靜態分析檢查的工具廣受開發者的歡迎。
不過現實是團隊裡不是所有成員都用 IntelliJ IDEA，而且在沒有圖型介面的 CI 主機上也很難執行 IntelliJ IDEA。若還是想用 Code Inspection 來檢查程式碼的話，現在 JetBrains 推出 Qodana 這個全新的程式碼品質檢查工具。概念上可以想像把 IntelliJ IDEA 的 Code Inspection 從 IDE 裡拔出來，為了方便使用，團隊把它以 Docker Image 封裝發佈，現在還提供 Qodana CLI 指令工具，讓開發者可以一行指令就把 Docker Image 運行起來，並用 Qodana 來掃描專案程式碼，並在檢查完成後提供詳細的報告，讓檢查工作更直覺簡單。
目前 Qodana 支援 Java/Kotlin、PHP、Python 及 JavaScript 等語言的 Linter，除了 CLI 指令工具外，也可整合 GitHub Actions、TeamCity、Gitlab CI、Jenkins 等 CI 服務。對於開發者來說，完全不需要在專案內做任何調整，只需在 CI 主機上設定 Qodana 一次，就可以在專案裡使用，非常方便。
在這邊要提醒讀者，若您使用的是 TeamCity Cloud，由於無法直接操控安裝 TeamCity Instance 的主機，無法自行安裝 Qodana 的 TeamCity Plugin，因此在做下一步驟前，請先透過客服與 TeamCity Cloud 維運團隊聯絡，請他們在你的 TeamCity Instance 上安裝 Qodana Plugin 後再進行。
要讓 TeamCity 執行 Qodana 檢查的方式很簡單，就是在原本的 CI Pipeline 增加一步 Build Step，指定使用 Qodana TeamCity Plugin 掃描專案程式碼即可。接續昨天的畫面，點擊右上角的 Edit configuration... 按鈕，進入專案的 Build Configuration 頁面，接著用左邊的選單切換到 Build Step 設定頁。
點擊 Add build step 按鈕，在目前的 Gradle Build Step 前新增一步。TeamCity 會把所有 Runner 清單列出，將頁面往下捲動找到 Qodana 後選 Select。
在 Qodana Runner 的設定頁，設定 Step name 為 Qodana（可依喜好自行設定）、Tools 選 Code inspection、Linter 選 Qodana for JVM，其餘保持預設值即可，設定好後按 Save 儲存。
一般來說，所有的程式碼檢查工作都會在 Build 之前執行，因此筆者想要調整 Build Step 的順序。回到 Build Steps 頁面，點擊畫面上的 Reorder build steps 按鈕，TeamCity 會彈出一個對話框，用滑鼠拖曳 Build Step 的名字來重新調整 Step 間的順序，讓 Qodana 是第一個、Gradle 是第二個，完成後按 Apply。
設定好 Qodana 後回到 Build Steps 頁，點擊右上角的 Run 按鈕再重新運行一次。由於 Qodana 掃描會需要比較長的時間，因此這次的 Build 總時長會比之前久一些。等 Pipeline 整個完成後，就可以在 Overview 看到這次的結果及 Qodana 的報告摘要。
報告裡有提到重大錯誤，點一下 See details in Qodana tab 連結，進到 Qodana 頁籤看完整報告。報告裡會分 Actual Problem、Baseline、Checks、Project Audit 等不同分頁，裡面會詳細的說明各項錯誤內容及等級。這邊的錯誤是筆者在練習時將 Package Name 寫錯，在抓 Class 時因此出錯，修改後再 Commit 及 Push 後，就可以修正這個警告了。
透過在 Pipeline 裡增加一步 Qodana 檢查，就可以在每次程式碼有變更時，多一隻公正的眼睛檢查，確認程式碼庫的品質，讓 TeamCity 發揮所謂 Quality Gate 的作用。
除了 Qodana 外，Kotlin 社群還有其他檢查工具可以使用，像是由 Pinterest 團隊推出的 ktlint 是一套用來檢查程式碼風格的工具，它可以直接從 Terminal 執行，也有整合好的 Gradle Plugin，其內建眾多由社群集結而成的 Rule Set，可以檢查專案內的程式碼是否符合 Style Guide，若有不通過的程式碼也有 Reformatter 可以一鍵修正。另外還有 detekt 也是社群裡知名的靜態分析器，其原理是從 Kotlin 編譯器取得語法樹後，依照內建 Rule Set 進行分析並提供改善建議。值得一提的是，現在也有針對 Compose 的語法檢查了。detekt 還支援多種輸出格式（XML、HTML、TXT），也有提供 Gradle Plugin 及 IntelliJ IDEA Plugin 方便整合。
由於 ktlint 及 detekt 都有與 Gradle 整合的 Plugin，要與 TeamCity 整合就變得更加容易。只要用今天筆記提到的方式，在 TeamCity 專案裡的 Build Configuration 多增加一步 Build Step，使用 Gradle Runner 執行對應的 Gradle Task 即可。對整合 ktlint 及 detekt 有興趣的讀者，可以瀏覽筆者於 2021 年鐵人賽的作品《DevOps 萌新的 TeamCity 極速上手寶典》 中 用 ktlint 做程式碼風格檢查 及 用 detekt 做靜態分析 兩篇的內容。
iThome鐵人賽
看影片追技術